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This invention relates to distributed computer systems. 



In certam fields of technology, compete computer systems, including a diversity of 
eompments, are optimized for storing and retrieving data. Such systems may provide 
- sendees to user machines related to a local network, e.g., an Intranet, or to a g looal 
network, e.g., the Web network. 

I. U desirable that network users ean access, upon a ouery, to a .arge number 
CS.ans,W,„oow s NT,.™ese^ 

an m ^ b y a direetot, server, ft^eroes^e^^^^,^^ 
of data be nrade possible m0 re rapidly for each queIy ^ ^ , fc( ^ 

* A genera aim of the present invention is „ provide advances jn ^ 

Broadiy.teeisprop.sedamethodoftap^ruentingapasswordcheckingiunction based 
on password-related data in a directory server system The H' , c " on ^ed 
dim ,,„„ ry server system. The directory server system has a 

drrectory server mtemcting with entries 0rg ani 2 ed in a tree structure. The entries 
compnsmg user entries. The method comprises the steps of- 
a) creating an additional entry, having attached password-related data, 

c) upon a cal. of the password checking thncou for me given entry, executing the 
m the addmona. enby designated by the extra data of the given user entry. 

There 1S also proposed a directory server capabie of mtemcting ^ entries h 
•tee square ,„ . d^ server system. The entries comprise user enLs. The 
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chrectory server has a password checking function capable of checking the password for 
a user entry, based on password-related data. Thepassword checking function is responsive 
to a user entry having extra data associated thereto, and identifying an additional entry, for 
executing a distinct password checking based on the password related data defined in that 
additional entry. 

This invention may also be defined as an apparatus or system, and/or as software code for 
.mplementing the method, or for use in the system, and/or as portions of such software 
code, in all their alternative embodiments to be described hereinafter. 

Other alternative features and advantages of the invention will appear in the detailed 
description below and in the appended drawings, in which : 

- Figure 1 is a general diagram of a computer system in which the invention is applicable- 

- Figure 2 illustrates a typical LDAP exchange between a LDAP client and a LDAP server,' 
and between the LDAP server and further servers; 

- Figure 3 illustrates the general structure of a LDAP directory; 

- Figure 4 shows a portion of a LDAP tree; 

- Figure 5 represents attribute types and values of an entry; 

- Figure 6 represents three types of LDAP roles according to the prior art; . 

- Figure 7 represents three types of LDAP classes of service according to the prior art; 

- Figure 8 illustrates the structure of a class of service, according to the prior art; 

- Figure 9 is a schema representing a structure for multiple password policies, in 
accordance with an embodiment of this invention; 

- Figure 1 0 illustrates the generation of a special role-based attribute for multiple password 
policies, according to an embodiment of this invention; 

- Figure 1 1 represents a portion of a directory tree in which the special role-based attribute 
for multiple password policies is generated, in accordance with an embodiment of this 
invention; 

- Figure 1 2 is a flowchart for executing password policy checkings on a given user entry, 
according to an embodiment of this invention; and 

- Figure 1 3 illustrates the subentry mechanism for scoping, defined in the ISO/IEC X.509 
standard. 
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In the foregoing description, references to th* p u-u- 

-0 Exhibit are piaced apart for 2 " '° * E * hi "« «■ TV 

e^eas.rrejr " ^ **" - of 

Now, making reference to software entities imposes certajll „ . 

Parties, - «*— between ■ T " 0,a,i0n ' 

'5 UDIF extracts and an expression in itaP u "ay be used to design 

" a " CS " e fo »™„g „ attribule ^ m 

As they may be cited in this specification Sun Su„ fcr 

trademarks of Sun Microsystems, Znc. ^ $W °™ « 

0 

A portion of the disclosure of this oatent h„ 
'ocopyrightpro.ection.The^^^ 
*anyo„eof tt epate„,d ^ 

author's rights whatsoever. a " ->*or 



~ Thehardware^Ilr 5 " ^ — « 

processor CPU 1 1, e.g. an Ultra-Sparc 
• a program memory 12 , e.g. an EPROM, a RAM, or F,ash mentory 

- a workmg memory ,3, e.g. a RAM of any suitab.e technotogy- 

- a mass memory 1 4, e.g. one or more hard disks; 



-a display 15, e.g. a monitor; 

- a user input device i 5, e.g. a keyboard and/or a mouse; 

- a network interface device 2. connected to a communication medium 20, which is in 
communication with other computers. Network interface device 2, may he of ,he type of 
Ethernet, or of the type of ATM. Medium 20 may be based on wire cables, fiber optics or 
radio-communications, for example. 

Data may be exchanged between the components of figure 1 through a bus system .0 
represented as a single bus for simp.ification of the drawing. Bus systems may include a 
processor bus, e.g. PCI, connected via appropriate bridges to, e.g. an ISA or a SCS. bus. 

The data exchanged are handled by a resource provider using a server to deliver data to 

user compulers.ortos.oremeda.aprovidedbytheusercomputers.Browsers.e.g. Interne, 
Explorer, are firrther provided on user compute., to enable users to make requests to 
rctneve or store data. The resource provider makes i. possible for user computers on a 
network to share data of any kind. 

iPlanc tE _ rc eSo.u,ions,„owSnnOncE_rceSo,u,io„s,hasdevelopeda»„et- 
enablmg" platfo™ called the Interne, Service Deployment Platefom, (ISDP) ISDP 

.ncludcsmuhiplcintegratedlayersofsofiwarethatprovideafirUscofservicessupporiing 
apphction development e.g. business-,o-business exchanges, communications and 
entertainment vehicles, and retail Web sites. 

Sun One™ Directory Server, provides a centialized directory service directoty service for 

anmtrane.oranex.ranet.Adirectoryservicerepresen.sacollectionofsoftware.hardware 
andprocessesthatareabletodeliverand store information. The directory service generally 
tncludes one or more directory client programs that can access the data stored in tire 
directory, e.g. names, phone numbers or addresses. 

The Sun One Directory Server is a general purpose directoiy that stores all inforniation in 
a single, network-accessible repository. The Sun One Directoty Server provides the 
standard protocol LDAP arrd an application programming interface (API) to aceess the 
information contained by the Sun One Directory Server. 
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LDAP is the Internet standard for director, ix u 

Protocol CHTTP-> i* a„ t ♦ Hypertext Transfer 

w LDAP queries and responses are carried over the IP network. 

"AM* and , high scalabi% . CU,ar ' y fitted fM ^ «** a hi gh 

Refemng now to figure 2, LDAP defines , communication 1 ben,, 
client 18 LDAPal^H.t; ™umcation 1 between a server 17 and a 

i5.LOAPalsodefines a communication2betweenrr)AP.. ., 
« to 17m, which makes i, possib.e for tb , LDAPserVCT,7a " d ^sl7.1 

il pvbswie tor the server IDAP n tA i 

(«o„ service) with servers 17, t0 , 7n „ "** "*"« 

servers 17 Itol 7 „, ref , , "° I? n ° r 10 ac « ss <■» directory of one of the 

'. to 1 7.n (referral service) and vice versa. 

™e LDAP protocol is a message-oriented protocol The client 1 « , . 
M — " * — and sends the 3 ^ 

Presses the ra^stand sends a resuh, or r esu„s, ack to ft e Z 8 " 
LDAP messages. Cnt 1 8 as a sene s of 

~tr^nr: ad — y - - * — ■ — - ™ 

•Hedireco, ™Ifi2 s 7 ""V" ^ *"« - -puter and 
onfourj cmode : ^ da,aarem0de,edM — ^ lly ,LDAPre„e S 



an information model; 

- a naming model; 

a functional model; and 

- a security model. 



- "MP motion mode, defines the kind of data that car, be stored in a d,rec,or, 



LDAP directory is populated with entries. An entry corresponds to real-world objects, such 
as a person, a printer, or configuration parameters. 

Figure 3 illustrates the general structure of a LDAP directory : the directory server 30 
5 executes implemented functions based on the entries 3 1 stored in databases. The entries 
comprise configuration entries 3 1 0, user entries 3 1 1 and administrative entries 312. These 
entries further interact with the schema 32 described below. The configuration entries are 
stored under the subtree "cn^config". The user entries comprise data related to the users 
of the directory server. Administrative entries relate to user management and are generally 
10 implemented as LDAP subentries. 

An entry contains a set of attributes associated with values. Each entry is uniquely 
identified by a distinguished name. The distinguished name may be stored in the dn 
attribute (distinguishedName). 
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LDAP entries are organized in a hierarchical tree structure, called the Directory 
Information Tree (DIT). Each node of the tree comprises an entry. Figure 4 illustrates an 
organization entry (22) with the attribute type of domain component dc, an organizational 
unit entry (24) with the attri bute type of organizational unit ou, a server application entry 
20 (26) with the attribute type ofcommon name cn, and a person entry (28) with the attribute 
type of user ID uid. The entries are connected by the directory. Each server has a particular 
entry called root directory specific entry (rootDSE) which contains the description of the 
tree and of its content. 

25 A LDAP Data Interchange Format (LDIF) is an ASCII text file format used to describe 
directory entries and operations on those entries. It enables to create, modify, and delete 
Directory entries and to import and export data among LDAP directories. Figure 5 is a 
LDIF representation of an entry 404, showing the attribute types 400 and their values 402. 

30 The information model is extensible, which means that new types of information can be 
added to a LDAP directory. 



Descriptive information is stored in the attributes of the entry. Each attribute describes a 



specific type of information. Attributes may have constraints that limit the type and length 
of data placed in attribute values. 

All entries require the objectclass attribute which lists the object classes to which an entry 
; belongs. An entry can belong to one or more object classes and must satisfy all of them. 
The objectclass attribute defines which attributes are required and which attributes are. 
allowed in the entry. 

For example, in figure 5, the entry (404) represented in LDIF belongs to the object classes 
top, person, organizationalPerson and inetOrgPerson. 

Each attribute has a corresponding syntax definition. The syntax definition describes the 
type of information provided by the attribute. The object classes, the required and allowed 
attributes, and the syntax definition of the attributes are listed in the directory schema. 

The LDAP directory comprises a structure 32, represented in figure 3, that defines object 
classes and attributes. This structure, called the schema, sets the rules defining what 
information can be stored in the LDAP directory and how information is organized. The 
schema specifies the required and allowed attributes that are used to store information and 
their syntax definition. A schema checking function may be activated, thus causing the 
directory server to check new entries to verify whether : 

- object classes and attributes attached to new entries are defined in the schema 32, 

- the attributes required for an object class according to the schema 32, are contained in 
an entry attached to that object class, 

- only attributes allowed by the object class according to the schema 32, are contained 
in an entry attached to that object class. 

The LDAP naming model specifies that directory entries must be hierarchical and 
organized in an inverted tree structure. As mentioned above, each entry has a unique name 
called a distinguished name dn. The dn consists of a list of the names of all the parent 
entries in the directory back to the top of the directory hierarchy, the name of the entry 
being at the extreme left, e.g., "uid=Joe,ou=people,dc=france,dc=sun,dc=com", in figure 
5. The root of the entry is at the extreme right of the dn. The name at the extreme left of 



the *, "„ i(Woe » in ^ examp , ei . ^ rela(ive d . t . ngujshed ^ m ^ ^ ^ 

m the directory tree cannot have the same <fc. 

5 LDAP nmctiona, mode, comprises eigh, basic mnoiona, operations (indicated 

the drrectory data of a LDAP directory server : 

- "bind" and "unbind" : begin and end the exchange of information between LDAP 
clients and the directory server; 

'0 - "add", "delete", and "modify" : apply on specific entries in the DIT 

- "compare" : apphes on two entries ,o compare their content according to criteria 
search" : locates specific entries in the DIT, 

- "™ d "yM>N»:appHes,ochange«hedis«ngni s hcdnameAofa„c„Uy. 

» b addition ,„ .he eigh, basic mncnonal operations, the LDAP protocol defines a 
framework for adding new operations ,„ the protoco, via LDAP extended operations 
Extended operations al.ow the protocol ,„ be extended in an orderly manner to meet new 
marketplace needs as they emerge. 

» A ^»— e^^ 

to smrphfy the management of LDAP users, Ro,es constitute one of those grouping 
mechamsms.Arokmay have member,, which are me e„«cs said to possess the role. Role 
mechan.sms enable the following operations: 

- enumerating the members of a given role, 

determining whether a given entry possesses a particular role, 

- enumerating all the roles possessed by a given entry, 

I- is taher possible ,o assign a particular ro ,e ,„ a given enhy and to revoke a particular 
™ e rom a given enfiy. Rol es can a,so be associated with penmssions, which a.,ows a 
tole-by-role access control management instead of a user-by-user access contro, 
management. 

Evety ro,e is defined by its own definition entry. A role is uniquely identified by the 
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distinguished name of its defining entry. R ole definition entries are LDAP Gentries and 
therefore mherit the subentry mechanism, defined in the ISO/IEC X.509 standard for 
scoping. ? 

5 Referring ,o figure 6, a role can be of Managed" type 601 , "filtered" type 602 or "nested- 
type 603. Each type of role farther has two specific object classes 61 that inherit from the 
. nsRoleDefinition object class. 

Roles can be used with a Cass of Service (CoS) to provide role-based attributes To 

all share the con™ attribute PoaalCoJe. Traditionally. ,„ change the postal code 
represented by the common attribute PoXalCode, an individual update of each entty is 
^^."WchconstiMesaheavyjobforadmifas.rators.Wi.hCoS.thegenera.ionofthe 
entty points t0 lhat place to give , va , ue their ^ ^ ^ ^ ^ ^ 

theattnbn.esgeneratedbyCoSappearjust.ikeallcherattnbutes.de.pitethat.heyareno,' 
actnafiy stored on the entries themselves. When coupled with roles, a CoS makes i« 
posstble to generate or update an attribute or role-based attribute for all the entries 
possessing the role. 



Figure.? illustrates the LDAP structure of a class of setvice. A class of service CoS is 
composed of the following entries in a LDAP directory: 

- a CoS Definition Entty 941 mat identifies the type of CoS. It is stored as a LDAP 
subentty be, 0 w the branch i, affects. The CoS definition entty more specifically 
■dentifies a CoS Template entty of the tree structure and targe, entries 

- aCoS '-P'^En, o ,98,0«hat g ivesvalues,oa„at,ribu,e,ide„ t ifiedbyac o ^^ 1 ,. 
tc.„,heCoSdefi„i,i„„ent^ the values beingautomaticnlly generated in mrgetentries 

y9 i . 

- Targe, entries 99 1 providing the attribute and attribute values dynamically genemted 
by the CoS definition entty and the template entty. Targe, entries share the sameparent 
as the CoS definition entty. 

Different types of CoS can be used depending on the way the value of dynamic attributes 



1U 

need to be generated. 
There are three types of CoS: 

s ~ lT e ^ comprisin8apo "^^ 

5 the template distinguished name only (link 3) 

- An indirect CoS designating the ,emp,a,e e„,ry using , he value of one ^ 
entry* annbu.es, identified by cosI^recSpecifler anribme (link „ 

'» de S1 gnated by cosS^cr attribute (IMS). 
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^^f^ 7 *'™"***^*****-.* andUteanribu.es „ 
of a COS definmon entty 701 and of a CoS tentplate entty 702 belonging ,„ a elassic CoS. 

A COS definition entty of a class.c CoS belongs ,o the object classes cosS m rDe finU io n 
and cosClass.cDef.nmon and comprises the attributes- 

- cosTe mplMeDN idenlifying , he d . ,. ngu . hed name of ^ ^ 

template entry, 

«>»er identifying the value of one of the large, entry's ahribu.es, and 

^^'*^^^ toTOiBtel ^ aI1Iytaed0llllie 
ot the template entry. 
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A class, c COS ,s capable of generating a„ ribute values for „ ^ ^ ^ 
possessed by .he entty, which avoids generating M e a«ribu.e values for each one of .he 

r ca r ciass of ^ a c ° s — - «» « » 

r of :: cos ^ cn,nes "°- - - — « — - - ^ 



A roie-baaed attribute appears on an entty because .he en,ry possesses a particular roie 
^^^^^^^^^^ 



ler aepoi 



11 

entry. 



LDAP security model further provides LDAP controls for additional information to be 
supplied by users as part of a LDAP operation. One example of a LDAP control is a 
password policy control. Password policies are used to make it difficult for password 
cracking programs to break into the directory. For instance, a password policy control can 
be used to return information during a bind request concerning the password expiration 
state of the user's password. 

A password policy is a set of rules that define how passwords are used in a given system. 
The password policy mechanism provided by the directory server allows to control 
password parameters such as how short a password must be and whether users can reuse 
passwords. When users attempt to bind to the directory, the directory compares the 
password with the value in the password attribute of the user's directory entry to make sure 
they match. The directory server also uses the rules defined by the password policy to 
ensure that the password is valid before allowing the user to bind to the directory. 

LDAP password policies comprise control mechanisms, such as User-Defined Passwords, 
Password Change After Reset, Password Expiration, Expiration Warning, etc. 

Password policies ..further comprise password policy attributes which set the parameters of 
passwords policies mechanisms . For instance, the password attribute/ww swordMaxFailure 
specifies the maximum of consecutive failed bind attempts after which a user account will 
be locked. Password policy attributes comprise the attributes that belong to the 
passordPolicy object class defined in Exhibit El, such as PasswordMustChange, 
PasswordChange, PasswordMinAge, PasswordExp, etc. 

Referring to figure 3, the schema 32 contains the definition of the passwordPolicy object 
class, as well as the definition of the password policy attributes. The passwordPolicy object 
class, contains a set of administrative password policy attributes. 



Lockout password policy attributes are also defined in the schema. They prevent dictionary 
attacks against the password by counting the number of failed bind and locking the user's 



^va IU e St opa S i™~ 

••»«cx ai ,2tirr'' -,,tafc "*--^ 
20 r ::::: define spec,fic ~ — ~ — - - 

values as ex istlng u J ri W 7 U ' re defcin8 25 ^ P-™ rd po, icy attributes 
30 u S ere„ try eMneS,andCaCh,meadd ^<"o^W^ objeclclasstothe 



• invention addresses (he above problems. 
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LIZ asetofuseK '^ toad -'-~™- hanismcontrolslothe 

Referring to figure 9, a directory tree structure accordino , a. ■ 

a se, of password policy entries 9, each ' ' nVen "° n 

passwordpolicy Ac ordiL, 1 ^ *»*• 3 

poncy.Accordmgtothemvention.thedirectoryserveriseanaM^f • • 
a given user entry E0 fr„ m user entries 991 with „ " n ""°»-«*rf-««*«« 

'» fron, password po.icy entries 9„ • „ " " *** P1 

PI to the user entry Eo ' ln orc *er to apply the password policy defined by entry 

More specifically, user entries may be previous!* *». u a 

one of the policy password policy ntTI „ ' ^ ^ 

• associating a given user e l eTI ^ ^ " «» 

riser entry E0 with a particular password Dolicv Pi in 

gtven enuy E0 comprising the special attribute and * the ™ '° 

password policy enhy PI flink 21 M ^ ''"^''"S 

According to another embodiment of the invention a , 
«-di S „„g U ,^ 

laentihes the password policy attribute 
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values to be used for executing password policy checkings. 



Exhibit E5 . 1 comprises an example of PasswordPolicySubentry attribute definition, in the 
schema of iPlanet (now "Sun One") Directory server. 

5 

An exemplary password policy entry is shown in Exhibit E4. 1 . A password policy entry, 
according to the invention, comprises : 

- a distinguished name identifying the entry, e.g. "dn : pwp_l , <suffix>", 

- the passwordPolicy object class ("object class : passwordPolicy "), 

,0 - a set of password policy attributes and attribute values, e.g. "PasswordMinAge : 0". 

The set of password policy attribute and attribute values characterizes a password policy 
entry. 

15 The passwordPolicySubentry attribute is attached to user entries in order to identify an 
associated password policy entry and thus the password policy attributes values to apply 
to each user. 

Defining the password policy attribute values out of the user entry makes it easier for the 
20 administrator to add/ modify or delete these values. 

Figure 12 is a flowchart representing the operations performed by the directory server for 
executing the password policy checkings on a given user entry EO. 

25 In response to a bind request, or a modify request on a user's password attribute 
(UserPassword) at operation 1 01 , the directory server gets the corresponding user entry 
EO at operation 103. 

At operation 1 05, the directory server checks whether user entry E0 has the PasswordPoli- 
30 cySubentry attribute. 

If user entry E0 is attached to PasswordPolicySubentry attribute, the directory server gets 
the password policy entry PI , whose distinguished name is the value of PasswordPoli- 
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cySubentry attribute, at operation 1 07. 



0 

• *- — — — 

•fenny EO is no, attached to ta.*^ attribme 
does „ ot exist « ,„ e DIT m 109) , at operation , , ^ J~ ^ W 
Password policy entry D0 , defined in the *™ - 3 *** 

'0 policy cn=confi 0 »Th- ^ onl,gura,,o„ 3 11 under entry "en- password 

If the default password policy entry DO is no, present the director . 
» code,- password policy anributes a( J tion J* server 8 e,s W 

If the default password policy entry DO is present th, a- . 

policy attributes value, d.r „ , ^ ^ 

V nbutes , alues defined ,„ th ls default entry, at operation 1 1 9 
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A. operation I21 , tne direct0Iy se „ er ^ _ ^ 

^ ~ "*» «*~ va,ues obtained at operation 11 7 or 1 1 9 °" 



- =f ====== 



servtce based on the roles possessed by the user entry. 

According to the prior art , . classic class of ' 
-loes for an entry based on ,he role possessed by rbeZ 1 h 
annbute values for eaeb one of tbe entries of fi,e 1 
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According to an embodiment of the invention, with reference to figure 10, the 
PasswordPolicySubentry attribute is generated as a role-based attribute. More specifically, 
cosAttribute in the CoS definition entry designates PasswordPolicySubentry and CoS 
template entries give values to PasswordPolicySubentry attribute. Thus, instead of directly 
attaching this attribute to user entries, PasswordPolicySubentry attribute is generated based 
on the roles possessed by user entry EO. 

As PasswordPolicySubentry attribute is operational, the template entries 980 that generate 
this attribute are not added a special object class. 

According to the prior art, generated attributes or role based -attributes are obtained using 
the nsrole attribute as the value of cosSpecifier attribute in the CoS Definition entry. 

With reference to figure 1 0, a role-based attribute is generated by the following operations 
of the prior art: 

- computing nsrole for a given target entry EO, 

- from the roles 970 identified by nsrole, and from the cosTemplateDN value determi- 
ning the CoS Template entry Tl, 

- getting in this CoS template entry Tl the value of the attribute identified by cosAttribu- 
te in the CoS Definition entry 940, and generating this value in the target entry E0. 

According to the prior art, the role entries 970, the CoS definition entry 940, the template 
entry identified by cosTemplateDN attribute should be located in the same level in the 
directory tree. 

Figure 1 1 illustrates a portion of a tree structure representing an exemplary classic CoS 
generating PasswordPolicySubentry attribute and attribute value for a target entry, in 
accordance with the invention. Exhibit E4.3 contains the LD1F definition of the represented 
entries. 



The user entry 9900 "cn=rob"is a target entry of the class of service defined by the CoS 
definition entry 9400. 
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The CoS attribute PasswordPolicySubentry ("cosAttribute ^PasswordPolicySubentry ") 
is generated as indicated by "CosSpecifier : nsRole *'. 

The user entry 9900 possesses the role entry 9700, as is indicated by "nsRoleDN: 
cn=nsPwpExampleRole, <suffix>". Thus, this role will be a value of nsrole attribute, when 
computing wrote for entry 9900, according to the operations described above. 

The distinguished name of role 9700 "ch=nsPwpExampleRole,<suffix> M and the 
cosTemplateDN value M cn=nsPwpTmp" provide a distinguished name 
'*cn=nsPwpExampleRole,<suffix>, cn=nsPwpTmp " that identifies the CoS template entry 
9800. 

The CoS attribute identifies the attribute PasswordPolicySubentry and the CoS template 
entry 9800 determines the value of this attribute "PasswordPolicySubentry:cn=pwp_l, 
<suffix>". PasswordPolicySubentry attribute and its value are then generated for the user 
entry 9900. 

Consequently, user entry 9900 is attached PasswordPolicySubentry attribute with the value 
"cn=pwp_l,<suffix>". 

The directory server, then- applies the flowchart of figure 12 for determining the password 
policy to apply to user entry 9900. For example, with reference to figure 1 1 , the directory 
server may determine that the password policy entry 9100 identified by "cn=pwp_l, 
<suffix>" exists in the DIT, and therefore apply the value <attributel>, <attribute2>, <attri- 
bute2> and so on, as password policy attribute values for executing password policy 
checkings. 

According to the invention, the password policy entry PI should be located at the same 
level as the role entries 970, the CoS definition entry 940 and the template entry, identified 
by cosTemplateDN attribute. 

Defining PasswordPolicySubentry attribute as a role-based attribute makes it possible for 
the administrator to dynamically assign the same group of entries without actually 
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modifying.^^d.omodifyftedesiredpasswordpoii^bych^ga^g^^^, 
CoS template entry). 

'"-"veerobod-nta^ 

■s real. The administrator defines direcfly in lhe „ ser entry 0* paswordPoHcySubenty 
a«nbu,e and attribute value. An example of a user entty comprising a real 
passwordPolicySubenlry attribute is shown in Exhibit E4.4. 

A " OTdi "^"ime„ M ^^^^ 

be located in the seope of tha, entty, which is defined as the subtree of the parent entry of 
the password poiiey entty. Figure ,3 iUustrates the subentty mechanism for scoping 
defined in the .SO/.EC X.509 standard. User entries EO. and E02 are in the seope S, of 
the password policy entty P., and ,herefo re can be associated with mis entty ,„verse ly 
user entty El I is out of the scope of password poiicy entry P, and therefore canno, be 
1 5 associated with entry PL 

Consequenfiy.withreferencetotheflowcharioffigure ^operation 109fnrthercomprises 
determining whether the user entty EO is in me scope ofthe password policy entry P, and 
■f not, getttng the default password policy entty at operation 1 1 1 

0 

According ,„ this embodiment, the administrator has to modify every single entty t o add 
passvordPolicySubentry attribute and attribute value. 

Additionally, ^ passwordPolicySubemry attribute mns, be controlled by an Access 
Control Instruction (ACI) in order ,„ prevent an unauthorized user from modifying this 
attribute. An example of ACI is shown in Exhibit E5.2. 

h the prior art, the password policy configuration was stored under »c„=c„„fig» As a 
result, ,t was no, replicated mi had „ fce ^ m ^ ^ ^ ^ ^ ^ ^ 

■nvenuon, there is no more one global configuration fo, all the entries. Tne password 
poltcy may be entry-based or role-based and thus may be replicated. As for the default 
password policy entry that may be stored under »c„= password policy, c„=config» „ 
should be the same on all the replicas. 
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According to another embodiment of the invention, the password policy configuration data 
from "cn=config" of the prior art may be migrated in the default password policy entry. 

This invention also encompasses software code, especially when made available on any 
5 appropriate computer-readable medium. The expression "computer-readable medium" 
includes a storage medium such as magnetic or optic, as well as a transmission medium 
such as a digital or analog signal. Such software code may include data and/or metadata. 



This invention further encompasses the software code to be added to existing directory 
10 server functionalities to perform anyone of the various new functionalities, as described 
above, which may be used independently of each other. 

On another hand, a number of features have been positively described, using absolute 
language, to help understanding the LDAP example. Each such feature should be 
15 considered as exemplary only, and is not intended to restrict the scope of this invention 
in any way. 
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Exhibit El - Password P olicy attrihntPc 
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Password policy attributes belongs to passwordPolicy object class. Their values indicates 
the parameters for determining when and how a user can/must change his password. The 
following sections El.l to El.l 1 describe the main password policy attributes. 

El .2 - passwordMaxA gp 
This attribute holds the number of seconds after which a modified password will expire. 
If this attribute is not present, or if the value is 0 the password does not expire. 

i 

El .3 - passwordExp 

ON means that ihepasswordExpirationTime must be updated after a successful password 
modification (i.e, password expiration is set). 

El. 4 - pas swordMinJ.pn oth 
TTiis attribute holds the minimum number of characters that must be used in a password, 
if syntax checking is enabled. If this attribute is not present, no minimum password length 
will be enforced. 

El .5 -passwnrdlnHistory 
This attribute specifies the maximum" number of used passwords stored in the 
passwordHistory attribute. If this attribute is not present, or if the value is 0, used 
passwords are not stored in Xhc passwordHistory attribute and thus may be reused. 

El .6 - passwnr dChanpe 

This attribute indicates whether users can change their own passwords. If this attribute is 
not present, a value of ON is assumed. 

El .7 - passwordWarninv 
This attribute specifies the maximum number of seconds before a password is due to 
expire that expiration warning messages will be returned to an authenticating user. If this 
attribute is not present, or if the value is 0 no warnings will be sent. 
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El .8 - passwordCheckSvntax 
This attribute indicates how the password syntax will be checked while being modified or 
added. If this attribute is not present, or if the value is OFF. syntax checking will not be 
enforced. A value of OFF indicates that the server will check the syntax. In fact, only the 
passwordMinLength is checked. 

El .9 - passwordMustChange 
This attribute specifies with a value of ON that users must change their passwords when 
they first bind to the directory after a password is set or reset by the administrator. If this 
attribute is not present, or if the value is OFF, users are not required to change their 
password upon binding after the administrator sets or resets the password. 

E 1 . 1 0 - passwordStorazeScheme 
This attribute holds the schema tag name used to hash the userPassword attribute. 

El. 11 - passwordMinAge 
This attribute holds the number of seconds that must elapse between modifications to the 
password. If this attribute is not present, 0 seconds is assumed. 



Exhibit E2- Lockout p olicy attributes 
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2.1- passwordLockout 

This attribute indicates, when its value is "ON", that users will be locked out of the 
directory after a specified number of consecutive failed bind attempts. The maximum 
number of consecutive failed bind attempts is specified in passwordMaxFailure . If this 
attribute is not present, or if the value is "OFF", the account will not be locked when the 
number of failed bind attempts has been reached. 

2.2- passwordMaxFailure 

This attribute specifies the number of consecutive failed bind attempts after which a users 
account will be locked. If this attribute is not present, or if the value is 0, the account will 
not be locked due to failed bind attempts and the value of passwordLockoutDuration will 
be ignored. 

2.3- passw ordResetFailureCount 

This attribute holds the number of seconds after which the password failures are purged 
from the failure counter (= passwordRetryCounf), even though no successful authentica- 
tion occurred. If this attribute is not present, or if its value is 0, the failure counter is only 
reset by a successful authentication. 

2.4- passwordLockoutDuration 

This attribute holds the number of seconds that an account will remain locked due to too 
many failed bind attempts. If this attribute is not present, or if the value is 0 the account 
will be locked until reset by an administrator. 

2.5- passwordUnlock 

If passwordMaxFailure has been reached and the value of this attribute is OFF, it means 
that the account is locked until the administrator resets it. If passwordMaxFailure has been 
reached and the value is ON, the account is locked for passwordLockoutDuration seconds. 
If accountUnlockTime is 0 and the value of this attribute is OFF, the account is locked 
until the administrator resets it. 
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Exhibit E3- Operatio nal Password Policy atftjbutgs 

E3 . 1 - passwordHistory 
This attribute holds a history of previously used passwords. 

E3 .2- pass wordAUowChan ge Timp. 

This attribute is used to specify the exact time after which the user is allowed to change 
his password. 

E3.3- passwnr dExvirationTimp. 
This attribute is used to specify the exact time after which the user's password expires. 

E3.4- pasxwnrd ExDWarne.d 
This attribute contains the time when the password expiration warning was first sent to the 
client. The password will expire in the passwordWarning time. 

E3. 5-passwordRetrvCnunt 

This attribute is used to count the number of consecutive failed attempts at entering the 
correct password. 

E3 . 6-retry Cnunt ResetTime 
This attribute, specifies the exact time after which the passwordRetryCount is reset 

E3.7- acco untUnlockTimP 
This attribute refers to the exact time after which the entry can be used for authentication. 
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Exhibit E4- entry definitions according to the invention 
E4.1 - Password Policy entry 

dn: cn=pwp__l, <suf f ix> 
5 objectclass: top 

objectclass: passwordPolicy 
ob j ectclass : LDAPsubentry 
passwordMinAge : 0 
passwordMaxAge : 8640000 
10 attributes of passwordPolicy objectclass> 

E4.2- Default password policy entry 

dn: cn=Password Policy, cn=config 
objectclass: top 
15 cn : Password Policy 

objectclass: passwordPolicy 
passwordMinAge: 0 
passwordMaxAge: -8640000 

<attributes of passwordPolicy objectclass> 

20 

E4.3 - passwordPolicySubentrv is virtual: Roles/COS entries 
E4.3.1 - Role entry 

dn: cn=nsPwpExampleRole, <suf f ix> 
objectclass : LDAPsubentry 
25 objectclass: nsRoleDef inition 

objectclass: nsSimpleRoleDef inition 
objectclass : nsManagedRoleDef inition 
cn: nsPwpExampleRole 

30 E4.3.2 - CoS Template entry indicated bv the specifier 

dn: cn=nsPwpTmp f <suf f ix> 
objectclass: top 

objectclass: nsContainer 

35 E4.3.3 - CoS Template entry associated with role cn=nsPwpExampleRole 

dn: cn=\"cn=nsPwpExampleRole, <suf fix>\", cn=nsPwpTmp, <suffix> 
objectclass: top 
■ objectclass: extensibleObj ect 
obj ectclass : costemplate 
40 objectclass: ldapsubentry 
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cosPriority: 1 

passwordPolicySubentry: ch=pwp_l, <suffix> 
E4.3.4-CoS definition 

entry 

dn: cn=nsPwp__cos, <suf fix> 
objectclass: top 
objectclass : LDAPsubentry 
objectclass: cosSuper Definition 
objectclass : cosClassicDef inition 
cosTemplateDn: cn=nsPwpTmp, <suf f ix> 
cosSpecifier: nsRole 

cosAttribute : passwordPolicySubentry 

E4.4 : passwordPnli cvSubentry attribute is. real 

dn: cn=users, <suf fix> 
objectclass: . . . 

passwordPolicySubentry : C n=pwp_l, <suffix> 



Exhibit E5 - PasswnrHPn licvSubentry attribute 
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E5.1- Definition in the schema 

attributeTypes : (passwordPolicySubentry-oid NAME • passwordPolicySuben- 
try' DESC 'iPlanet defined password policy attribute type' SYNTAX 
1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'iPlanet Directory Server' USAGE 
directoryOperation) 

E5.2-Access control 

targetattr != \"passwordPolicySubentry\" ) (version 3.0; acl V" 
"Allow self entry modification except for passwordPolicySubentry » 
"allow (write) userdn =\"ldap: ///self \"; ) "; 
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Claims 

1. A method of implementing a password checking function based on password-related 
data in a directory server system. 

in which the directory server system has a directory server interacting with entries 
organized in a tree structure, and the entries comprising user entries, 
the method comprising the steps of : 

a) creating an additional entry, having attached password-related data, 

b) attaching extra data to a given user entry, the extra data designating the additional entry, 
and 

c) upon a call of the password checking function for the given entry, executing the 
password policy checking function for the given user entry based on the password-related 
data in the additional entry designated by the extra data of the given user entry. 

2 . The method of claim 1, wherein the additional entry of step a) has a scope in the tree 
structure, and step c) is performed subject to the given user entry belonging to the scope 
of the additional entry. 

3. The method of claim 2, wherein the scope of the additional entry comprises the subtree 
of the parent entry of that additional entry. 

4. The method as claimed in any of claims 1 through 3, wherein the additional entry of step 
a) has at least one attribute, whose value contains password-related data. 

5. The method of claim 4, wherein the value of said at least one attribute contains 
password policy data. 

6. The method as claimed in any of claims 1 through 5, wherein step a) comprises 
attaching an object class data to an additional entry, said object class data identifying a 
predefined object class associated with said password-related data. 

7. The method as claimed in any of claims 1 through 6, wherein step b) further comprises 
checking whether the tree structure comprises the additional entry, as identified by the 



extra data. 



8. The method of claim 2, wherein: 

- step a) comprises creating a plurality of additional entries, each having attached 
password-related data, the additional entries having different scopes in the tree structure, 
and 

- step c) is performed subject to the given user entry belonging to the scope of one of the 
additional entries. 

9. The method as claimed in claim 8, further comprising the step of : 

d) upon step c) being not performed or failing for a user entry, executing the password 
policy checking function on that user entry, using predefined password related data. 

1 0. The method of claim 1 , wherein the extra data of step b) designates the location of said 
additional entry. 

1L The method as claimed in any of claim 1 through 10, wherein step b) comprises 
directly adding the extra data to the given user entry. 

12. The method of claim 11, wherein step b) comprises adding the extra data to the given 
user entry in the form of an extra data attribute whose value designates the location of the 
additional entry. 

13. The method of claim 12, wherein the extra data attribute is an operational attribute. 

14. The method as claimed in any of claim 1 , in which the directory server has a class of 
service mechanism, wherein step b) comprises adding the extra data in the form of a class 
of service being applicable to one or more user entries. 

15. The method of claim 14, in which a class of service has a scope and said one or more 
user entries are located in the scope of the class of service. 

1 6. The method of claim 1 5, wherein the scope of a class of service comprises the entries 
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located in the subtree of the parent entry of an entry defining the class of service. 

17. The method as claimed in any of claims 14 through 16, in which the directory server 
has a role mechanism, wherein step b) comprises adding the extra data to a class of service 
being applicable to one or more user entries having the same role. 

18. The method as claimed in any of claims 14 through 17, wherein step a) comprises 
adding said additional entry in the same level of the tree as the entry defining the class of 
service. 

19. A directory server capable of interacting with entries organized in a tree structure in 
a directory server system, said entries comprising user entries, 

the directory server having a password checking function capable of checking the 
password for a user entry, based on password-related data, 

said password checking function being responsive to a user entry having extra data 
associated thereto, and identifying an additional entry, for executing a distinct password 
checking based on the password related data defined in that additional entry. 

20 . The directory server of claim 19, wherein the additional entry has a scope in the tree 
structure, and said distinct password checking is performed subject to the given user entry 
belonging to the scope of the additional entry. 

21. The directory server of claim 20, wherein the scope of the additional entry comprises 
the subtree of the parent entry of that additional entry. 

22. The directory server as claimed in any of claims 1 9 through 2 1 , wherein the additional 
entry has at least one attribute, whose value contains password-related data. 

23. The directory server of claim 22, wherein the value of said at least one attribute 
contains password policy data. 

24. The directory server as claimed in any of claims 19 through 23, wherein step a) the 
extra data comprises object.class data attached to the additional entry, said object class 
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data identifying a predefined object class associated with said password-related data. 

25. The directory server as claimed in any of claims 19 through 24, further comprising a 
mechanism for checking whether the tree structure comprises the additional entry, as 
identified by the extra data. 

26. The directory server of claim 20, wherein the entries comprise a plurality of additional 
entries, each having attached password-related data, the additional entries having different 
scopes in the tree structure, and said password checking function is responsive to a user 
entry belonging to the scope of one of the additional entries, for executing a distinct 
password checking based on the password related data defined in that one of the additional 
entries. 

27. The directory server as claimed in claim 26, wherein said password checking function 
is adapted to execute the password checking function on a user entry, using predefined 
password related data, when that user entry has no extra data associated thereto. 

28. The directory server of claim 19, wherein the extra data designates the location of the 
associated additional entry. 

29. The directory server as claimed in any of claim 19 through 28, comprising extra data 
being directly added to the user entry. 

30. The directory server of claim 29, wherein the extra data are added to the given user 
entry in the form of an extra data attribute, whose value designates the location of the 
additional entry. 

31. The directory server of claim 30, wherein the extra data attribute is an operational 
attribute. 

32. The directoiy server as claimed in any of claim 19 through 3 1 , in which the directory 
server has a class of service mechanism, comprising the extra data being added in the form 
of a class of service being applicable to one or more user entries. 
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33 . The directory server of claim 32, in which a class of service has a scope, wherein said 
one or more user entries are located in the scope of the class of service. 

34. The directory server of claim 33, wherein the scope of a class of service comprises the 
5 entries located in the subtree of the parent entry of an entry defining the class of service. 

35. The directory server as claimed in any of claims 32 through 34, in which the directory 
server has a role mechanism, comprising extra data being added in the form of a class of 
service being applicable to one or more user entries having the same role. 

36. The directory server as claimed in any of claims 32 through 35, comprising said 
additional entry being added in the same level of the tree as the entry defining the class of 
service. 

15 37. The software code for performing the steps of any of claims 1 through 1 8. 

38. The software code for a directory server as claimed in any of claims 1 9 through 36. 

39. A plug-in software code for a directory server, comprising additional code for a 
20 password checking, such that the password checking function responds to a user entry 

having extra data associated thereto, and identifying an additional entry, for executing a 
distinct password checking based on the password related data defined in that additional 
entry 
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40. The combination of the software code of claim 39 with the password checking 
function. \ /\ j 
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Attribute type ^.00 Attribute value 4 02 



dn : 


uid=Joe, ou=people, dc=france, dc=sun, dc=com 


objectClass : 


top 


objectClass : 


person 


objectClass : 


organizationalPerson 


objectClass : 


inetOrgPerson 


cn . 


joe 


sn : 


Rayan 


uid : 


joerayan 


mail : 


joerayan@sun .com 


phoneNumber : 


778 
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Role Type 


Object Classes 


Attributes 






Managed Role 


nsSimpleRoleDefinition 
nsManagedRoleDefinition 


description (optional) 




Filtered Role 


nsCompiexRoleDefinition 
nsFilteredRoleDefinition 


NsRoleDN 

description (optional) 




Nested Role " 


nsCompiexRoleDefinition 
nsNestedRoleDefinition 


NsRoleDN 
description (optional) 
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